In video distribution systems and in particular in wireless video distribution systems, there is a need to handle multiple input and output video streams and to apply particular data processing to each of them, before transmitting the output video streams or after receiving the input video streams.
The nature of the data processing tasks to be performed on such video distribution systems vary as a function of the applications handling the video streams and of the transmission characteristics. For the sake of illustration and from an application perspective, data processing tasks can relate to data compression, in particular for data transmission when the transmission bandwidth is limited. Still for the sake of illustration and from a transmission perspective, data processing tasks can relate to formatting data frames and frame headers and to computing cyclic redundancy check (CRC) data in accordance with the transmission protocol to be used.
Moreover, such data processing tasks are to be done in view of performance requirements that can relate, for example, to real time constraints.
Striking a balance between resource optimization and versatility in view of planed usages generally leads to choosing between a data-flow based computational model (data-flow driven architecture) and a control-flow based computational model (control-flow driven architecture).
According to the data-flow based computational model, a sequence of data processing tasks (also referred to as operations) is predetermined and does not need centralized management to organize data transfer between data processing tasks and does not need scheduling execution of data processing tasks. In such a model, execution of a data processing task is triggered by the availability of the requested input data (or operands).
On the contrary, according to the control-flow based computational model, execution of a data processing task is associated with the execution of a program counter that translates a user program description in the context of data processing resource distribution.
Therefore, a data-flow based computational model is advantageously used when the sequence graph of data processing tasks is rather static over time. It is well adapted to intensive data processing requirements. Conversely, a control-flow based computational model is adapted to a huge dynamic sequence of data processing tasks, for example data processing tasks of a transmission protocol. It is well adapted to scheduling data processing tasks.
To support both intensive data processing requirements and control requirements, a hybrid model such as the hybrid model known as XPP (eXtreme Processing Platform) can be used. It is a data processing architecture based on a hierarchical array of coarse-grain adaptive computing elements called Processing Array Elements (PAEs), and a packet-oriented communication network. Control-flow dominated, irregular code (without loop-level or pipelining parallelism) is mapped to one or several concurrently executing Function-PAEs (FNC-PAEs) which are sequential 16-bit processor kernels. Regular streaming algorithms like filters or transforms can be implemented in the dataflow part of an XPP processor array.
In XAPP architecture, XPP objects are self-synchronizing: an operation is performed as soon as all necessary data input packets are available. The results are forwarded as soon as they are available, provided the previous results have been consumed. Event packets transmit state information. Events generated by arithmetic and logical unit (ALU) objects depend on ALU results or exceptions, in a way that is very similar to the state flags of a conventional microprocessor. These events are used to control the subsequent data processing tasks.
However, such a solution does not address resource optimization and latency control over intensive data processing.
In order to optimize the price of electronic circuits or chips embedding such data processing capabilities, for several contexts of use (application and transmission characteristics), one should rationalize architecture execution resources to provide a versatile circuit instead of multiplying specific implementations.
Accordingly, to solve these issues, there is a need for a configurable circuit architecture adapted to handle various performance constraints, to support processing based functional requirements (to handle data processing tasks from application perspectives), and to support protocol based functional requirements (to handle data processing tasks from transmission perspectives).